Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JanusGraph release candidate 1.0.0-rc1 [cql-tests] [tp-tests] #3350

Merged
merged 1 commit into from
Dec 7, 2022

Conversation

FlorianHockmann
Copy link
Member

@FlorianHockmann FlorianHockmann commented Nov 29, 2022

Once this PR is merged, I'll continue with the release process and publish the release candidate (or better to say: let our new awesome release process do it). So, if there are issues with the current state on master or anything that you think should be included for this release candidate, then please comment here.

I've followed the release docs, but did not change the changelog.md because I assumed that we don't want to include release candidates there. People can check out the unfinished entry for 1.0.0 there to get an idea of the changes for 1.0.0-rc1. I think that should be enough for a release candidate.

Discussion thread: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/95312566

@janusgraph-bot janusgraph-bot added the cla: external Externally-managed CLA label Nov 29, 2022
Copy link
Contributor

@farodin91 farodin91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get this out of door and merge other PRs into 1.0.0-rc2 or?

@FlorianHockmann
Copy link
Member Author

merge other PRs into 1.0.0-rc2 or?

You mean merge them into master which we can then later release as 1.0.0-rc2? In that case, yes, that was my idea. (Although it's not clear of course whether we'll have a rc2 at all.)

@farodin91
Copy link
Contributor

Why not?

@FlorianHockmann
Copy link
Member Author

Why not?

Why we maybe won't have a rc2? If we don't uncover any problems with rc1 and don't add many breaking changes after rc1 is finished, then we maybe won't see a reason to publish another release candidate and instead directly release 1.0.0.

@farodin91
Copy link
Contributor

Yeah, but have some PRs in the pipeline. So, we could release already a rc1 and get them in before 1.0 so it could be interesting to publish a rc2 before release with freeze phase.

@FlorianHockmann
Copy link
Member Author

it could be interesting to publish a rc2 before release with freeze phase.

Yes, sure, I'm also not against doing another release candidate after this. But it could also happen that we get basically no feedback to rc1 and therefore don't see much reason to publish a rc2 after that, especially if there are no big breaking changes happening between rc1 and the final 1.0.0 release.

Copy link
Member

@li-boxuan li-boxuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for leading the release procedure!

Copy link
Member

@porunov porunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. Thank you @FlorianHockmann !

I have several small notes but otherwise it looks good to me.

  • I don't know if we need a separate release notes for rc1 release in docs/changelog.md . I.e. if rc1 release will be always available than we probably need separate release notes because rc1 release and the final release will probably have different upgrade instructions in case we implement more breaking changes into the final release. In case we plan to remove access for rc1 release than we don't need additional release notes for this release.
  • (not related to this PR) When we publish the release, we need to be clear that some more breaking changes are expected.
  • (not related to this PR) We also may need to tell users where to leave their comments regarding the rc release. (should we tell users to add comments to the next thread? https://lists.lfaidata.foundation/g/janusgraph-dev/topic/95312566 )

@@ -166,7 +166,7 @@ nav:
- Changelog: changelog.md

extra:
latest_version: 1.0.0
latest_version: 1.0.0-rc1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this influences JanusGraph documentation generation or not. I do remember that it has some specific format like x.y.z but not sure about x.y.z-rc1 format. Probably documentation generation should be fine but I think @farodin91 knows better about the docs generation process, so I will rely on his comments to this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

latest_version is just a string replace.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just searched where it's being used and there are some places in the docs. These fall in 3 categories:

  1. Name of the distribution build: janusgraph-{{ latest_version }}.zip
  2. As the version of the JARs to depend on
  3. In the URL for Java docs.

The zip archive should include this version and the JARs will also have it so points 1 and 2 are fine. I would also expect the deployment to publish the Java docs although I'm not 100% sure on this. However, there are only 2 links in the docs to the Java docs so it shouldn't be a big problem.

So I'll go ahead now and merge this to proceed with the deployment.

@FlorianHockmann
Copy link
Member Author

I don't know if we need a separate release notes for rc1 release in docs/changelog.md . I.e. if rc1 release will be always available than we probably need separate release notes because rc1 release and the final release will probably have different upgrade instructions in case we implement more breaking changes into the final release. In case we plan to remove access for rc1 release than we don't need additional release notes for this release.

I've basically already wrote my thoughts on this in the PR description (not sure if you saw that):

I've followed the release docs, but did not change the changelog.md because I assumed that we don't want to include release candidates there. People can check out the unfinished entry for 1.0.0 there to get an idea of the changes for 1.0.0-rc1. I think that should be enough for a release candidate.

If we want to add separate upgrade instructions for the release candidates into the changelog, then we either have to copy these into the final instructions again or expect people to read through the upgrade instructions of (possibly) several release candidates and then the final release.
I don't really like both options personally and instead prefer to only give some hints in the release description in GitHub. We can there link to the changelog for the unfinished 1.0.0 release. (Although that is of course subject to change if we merge more breaking changes.)
Alternatively, we could maybe copy the changelog entry for 1.0.0 into the release description of the rc release in GitHub.

(not related to this PR) When we publish the release, we need to be clear that some more breaking changes are expected.

(not related to this PR) We also may need to tell users where to leave their comments regarding the rc release. (should we tell users to add comments to the next thread? https://lists.lfaidata.foundation/g/janusgraph-dev/topic/95312566 )

I was thinking about announcing the release candidate on janusgraph-users. We can then inform about the breaking changes there and ask users to also directly submit feedback there (which is then only a reply to the email).

@porunov
Copy link
Member

porunov commented Dec 1, 2022

I've basically already wrote my thoughts on this in the PR description (not sure if you saw that):

I checked that couple days ago and then forgot about your points today :)
Yeah, your points regarding instructions regarding release candidates make sense. I guess we don't need many instructions which will look the same. I would prefer hints in the final release in such case as you suggested.

I was thinking about announcing the release candidate on janusgraph-users. We can then inform about the breaking changes there and ask users to also directly submit feedback there (which is then only a reply to the email).

Yes, that definitely makes sense.

Copy link
Member

@porunov porunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you @FlorianHockmann !

@FlorianHockmann FlorianHockmann merged commit f35a903 into master Dec 7, 2022
@FlorianHockmann FlorianHockmann deleted the release-1.0.0-rc1 branch December 7, 2022 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: external Externally-managed CLA
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants